Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
src/Http11Probe/TestCases/Suites/ComplianceSuite.cs:431 treats 400 as Pass and 2xx as Warn; glossary says the same at docs/content/docs/request-line/absolute-form.md:13.
RFC 9112 says a server MUST accept absolute-form, so 400 should not be Pass.
src/Http11Probe/TestCases/Suites/ComplianceSuite.cs:751 allows 400 as Pass; glossary mirrors this at docs/content/docs/body/chunked-extension.md:13.
RFC 9112 §7.1.1 says recipients MUST ignore unrecognized chunk extensions; for this short valid extension payload, 400 is not a good pass outcome.
src/Http11Probe/TestCases/Suites/SmugglingSuite.cs:140 only accepts 400/close; glossary same at docs/content/docs/smuggling/te-trailing-space.md:13.
RFC 9110 §5.5 says trailing OWS is excluded before evaluating field value; plus RFC 9112 allows CL+TE requests to be rejected or processed with TE (with connection close). So 2xx (with
close) should not be an automatic fail.
src/Http11Probe/TestCases/Suites/SmugglingSuite.cs:1189 requires exact 400; glossary same at docs/content/docs/smuggling/te-obs-fold.md:13.
RFC 9112 §5.2 allows two compliant server behaviors: reject with 400 or replace obs-fold with SP and continue parsing.
src/Http11Probe/TestCases/Suites/SmugglingSuite.cs:124 and src/Http11Probe/TestCases/Suites/SmugglingSuite.cs:819 only pass on 400/close.
RFC 9112 §6.1 says unknown transfer coding SHOULD get 501 Not Implemented; that should be accepted (at least Warn/Pass).
Code at src/Http11Probe/TestCases/Suites/ComplianceSuite.cs:773 effectively passes only 426 (or warns on 2xx) and fails other non-101 errors.
Glossary says 426 or any non-101 at docs/content/docs/upgrade/upgrade-invalid-ver.md:13.
RFC 6455 says abort handshake and send an appropriate HTTP error (e.g. 426), so other non-101 error codes should not fail by default.
Docs/Project consistency issues
docs/content/docs/smuggling/chunked-with-params.md:12 vs src/Http11Probe/TestCases/Suites/SmugglingSuite.cs:903 (no Scored = false).
No dedicated glossary pages for: SMUG-CHUNK-EXT-CR, SMUG-TE-VTAB, SMUG-TE-FORMFEED, SMUG-TE-NULL, SMUG-TRAILER-AUTH (and baseline COMP-BASELINE).